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(S) Apparatus and methods for implementing protocols. 



@ Apparatus and methods for communicating using protocols. The apparatus and methods employ 
protocol descriptions written in a device-independent protocol description language. A protocol is 
executed by employing a protocol description language interpreter to interpret the protocol descrip- 
tion. Communication using any protocol for which there is a protocol description may be done by 
means of a general protocol. The general protocol includes a first general protocol message which 
includes a protocol description for a specific protocol. The protocol apparatus which receives the first 
protocol message employs a protocol description language interpreter to interpret the included 
protocol description and thereby to execute the specific protocol. The protocol apparatus may also be 
made to adapt to its environment by encaching protocol descriptions which were received in an earlier 
first general protocol message and interpreting an encached protocol description in response to a 
second general protocol message which includes a protocol identifier specifying the encached protocol 
description. 
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means capable of interpreting the protocol description language to interpret the protocol description as 

required to communicate using the specific protocol. 
In still another aspect the invention is protocol apparatus for communicating in distributed system, the appa- 
ratus including: 

. means for receiving a first general protocol message, the first general protocol message including a pro- 
tocol description which describes a specific protocol and which employs a protocol description language 
which is independent of any particular implementation of the protocol apparatus; and 

. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
specific protocol. 

In a further aspect, the invention is apparatus for communicating in a distributed system, the apparatus includ- 
ing: 

. first protocol apparatus for communicating using a general protocol and 
. second protocol apparatus for communicating using the general protocol, 
. the first protocol apparatus including 

. means for providing a first general protocol message which includes a protocol description which de- 
scribes a specific protocol and which employs a protocol description language which is independent of 
any particular implementation of the second protocol apparatus; and 

. means for employing the specific protocol to communicate with the second protocol apparatus after pro- 
viding the first general protocol message; and 

. the second protocol apparatus including 

. means for receiving the first general protocol message from the first protocol apparatus; and 

. means for responding to the first general protocol message which are capable of interpreting the protocol 

description language and which interpret the protocol description as required to communicate using the 

specific protocol. 

The foregoing and other aspects, objects and advantages of the invention will be apparent to one of ordinary 
skill in the art who peruses the following Drawing and Detailed Description, wherein: 

Brief Description of the Drawing 

FIG. 1 is a block diagram of a typical system in which protocols are used; 

FIG. 2 is a block diagram of a first apparatus incorporating the invention; 

FIG. 3 is a block diagram of a second apparatus incorporating the invention; 

FIG. 4 is a table of instructions in a protocol description language; 

FIG. 5 is a flowchart of the bootstrap state; 

FIG. 6 is a flowchart of the error state; 

FIG. 7 is a state diagram for the alternating bit protocol; 

FIG. 8 is a protocol description for the receive side of the alternating bit protocol; 

FIG. 9 is a protocol description for the send side of the alternating bit protocol; 

FIG. 1 0 is a fragment of the transition procedure; 

FIG. 11 is a protocol description for the bootstrap state; 

FIG. 12 is a protocol description for the error state; and 

FIG. 13 is a block diagram of an embodiment which encaches downloaded protocol descriptions. 

The reference numbers employed in the Drawing and the Detailed Description have three or more digits. 
The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, 
the element with the reference number "305" is first shown in FIG. 3. 

Detailed Description 

The following Detailed Description will first provide an overview of the techniques of the invention and will 
then disclose in detail how the Alternating Bit Protocol (described at Holzmann, supra, pp. 75-77) may be im- 
plemented using the techniques of the invention. 

Overview: FIGs. 1*3 

FIG. 1 is a block diagram of a system 101 in which protocols are used for communication between a first entity 
109(1) and a second entity 109(2). Each entity 109 includes a source or destination 103 for information (INFO) 
105 and a protocol apparatus 107. 
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mentations of protocol apparatus 201 will implement different versions of the protocol. Second, protocol de- 
scription 203 is written only once, but will be used many times. It is therefore worthwhile to expend great efforts 
to ensure that protocol description 203 is in fact a correct, complete and unambiguous description of the pro- 
tocol. Third, the part of protocol apparatus 201 which may differ in the different implementations is protocol 
execution device 207. However, protocol execution device 207 must now only be able to correctly execute the 
protocol instructions 205 in protocol description 203. That is, the problem is no longer the correct implemen- 
tation of the protocol, but rat her the correct implementation of an instruction set in a single device. This problem 
is, however, far better understood than the problem of implementing a protocol in two devices, and consequent- 
ly, implementations of the protocol instruction set in different protocol apparatuses 201 are far more likely to 
be correct than implementations of the protocol itself. 

Apparatus for Executing a General Protocol: FIGs. 3 and 13 

Perhaps the most significant advantage of protocol apparatus 201 is that it can execute any protocol for 
which there is a protocol description 203 written in the protocol description language. Consequently, protocol 
apparatus 201 can easily be modified to make a general protocol apparatus which executes a general protocol 
and which can therefore dynamically execute any protocol for which there is a protocol description 203. The 
general protocol is simply the following: 

. in a sending protocol apparatus, sending a general protocol message which includes a protocol descrip- 
tion 203; 

. in a receiving general protocol apparatus, employing protocol instruction interpreter 209 to execute the 
protocol description 203 contained in the general protocol message. 

FIG. 3 shows such a general protocol apparatus 301. General protocol apparatus 301 includes protocol 
instruction interpreter memory (PIIM) 309, which contains protocol description 203 for the protocol currently 
being executed by protocol apparatus 301 and protocol instruction interpreter data (PIIDATA) 311, which is data 
employed by protocol instruction interpreter 209 in executing protocol description 203. Protocol interpreter 209 
has two additional components: bootstrap component (BOOT) 305 and error component (ERR) 307. These 
components make it possible for general protocol apparatus 301 to execute the general protocol, and thereby 
make it possible for any protocol apparatus 107 which can provide a protocol description 203 to protocol ap- 
paratus 301 to use the protocol described in the protocol description 203 to communicate between the entities 
109 to which protocol apparatus 107 and protocol apparatus 301 belong. Of course, both protocol apparatuses 
involved in the communication may be general protocol apparatuses 301. 

Protocol apparatus 301 executes the general protocol as follows: bootstrap 305 listens for a general pro- 
tocol message (indicated by arrow 313) from the other protocol apparatus. In a preferred embodiment, the 
general protocol message uses the same path between the protocol apparatuses as does protocol data 111. 
In other embodiments, there may be a special path for the general protocol message. The general protocol 
message further contains at least the first part of protocol description 203 for the specific protocol to be exe- 
cuted. When bootstrap 305 receives the general protocol message, it loads the message into a buffer in pro- 
tocol instruction interpreter data 311 and performs checks as described below. If the message passes the 
checks, bootstrap 305 loads the general protocol message into the portion of memory 309 reserved for protocol 
description 203. Thereupon, interpreter 209 begins executing the protocol instructions 205 in the message, 
beginning with the initial instruction. If protocol description 203 is longer than the maximum size of an general 
protocol message, then the first part of protocol description 203 contains protocol instructions which, when 
executed, cause the rest of protocol description 203 to be loaded. 

In a preferred embodiment, the general protocol requires that the general protocol message contain check- 
ing information which permits error checking and protocol data information which indicates how protocol in- 
struction interpreter 209 is to interpret protocol data 111 and that the receiving general protocol apparatus 301 
use the checking information and the protocol data information. In the preferred embodiment, there are two 
items of checking information: a checksum for the general protocol message and a required first instruction. 
On receiving the general protocol message, bootstrap 305 computes the general protocol message's check- 
sum and compares it with the checksum in the message; if they are different, there has been a transmission 
error and bootstrap 305 waits for another general protocol message. If bootstrap 305's check of the required 
first instruction in the general protocol message indicates that the general protocol message is not a protocol 
description 203, the error component 307 of protocol instruction interpreter 209 returns an error message (in- 
dicated by arrow 31 5) to the protocol apparatus 101 which provided the general protocol message. Thereupon, 
error 307 waits for a valid general protocol message. Once the general protocol message has been successfully 
received, it is executed by protocol instruction interpreter 209, and as part of the execution, the protocol data 
information in the general protocol message is used to set parameter values in protocol instruction interpreter 



4 



EP 0 555 997 A2 

scription. 

As will be explained in more detail below, the protocol descriptions 203 employed in a preferred embodi- 
ment define a finite state machine. Consequently, a given protocol description 203 is divided into a set of num- 
bered states (S)1 321 . To permit location of the states, protocol description 1 311 is divided into two parts: pro- 

5 tocol description body (PDB) 1314, which contains the instructions for the states, and state table 1313, which 
relates state numbers to the locations of the corresponding states 1321. There is an entry 1315 in state table 
131 3 for each state 1321 in the protocol description body, and each entry contains the state number (SN) 1317 
and the offset (OFF) 1319 of that state from the beginning of protocol description 1311. 

The modifications required in bootstrap 305 will be immediately apparent from FIG. 13 and the description 

10 of the general protocol for general protocol apparatus 1323. When a general protocol message is received 
which contains a protocol description identifier for which the protocol description! 31 1 is in memory 1302, boot- 
strap 305 simply causes interpreter 209 to begin executing the specified protocol description; otherwise, boot- 
strap 305 retains the identifier from the general protocol message and causes error 307 to return an error mes- 
sage and wait for a message which contains the protocol description 1311. When the message arrives, error 

15 307 causes bootstrap 305 to compare the retained identifier with the identifer in the general protocol message 
containing the protocol description 1311, and if they agree, bootstrap 305 places the protocol description 1311 
in memory 1302 and makes an entry 1305 for the new protocol description 1311 in protocol description table 
1303. 

Of course, many variation on the above arrangements are possible. For example, memory 1302 is nec- 
20 essarily finite; consequently, bootstrap 305 may have to remove one protocol description 1311 to make room 
for another. One way of doing this would be to include size and most recent use information in protocol de- 
scription table 1303, and bootstrap 305 could use that information to determine which protocol descriptions 
1311 should be removed. Further, the general protocol for general protocol apparatus 1323 might include a 
checksum in the general protocol message for the protocol description 1311 identified by the identifier. Boot- 
25 strap 305 could use the checksum to make sure that the copy of the protocol description 1311 in memory 1302 
was the same as the copy held by the sender. If it was not, bootstrap 305 could send an error message re- 
questing the protocol description and then proceed as previously described for protocol descriptions for which 
there was.no copy in memory 1302. 

30 Implementation of Protocol Apparatus 301 

A prototype implementation of protocol apparatus 301 has been constructed in which protocol execution 
device 207 is a computer capable of executing programs written in the well-known "C" programming language. 
In the prototype implementation, protocol instructions 205 belonging to a protocol description language are 

35 interpreted by a protocol instruction interpreter which is written in C and is executed by a process running on 
the computer. General protocol apparatus 301 has been tested by writing a protocol description 203 for the 
alternating bit protocol in the protocol description language and executing the protocol by executing the pro- 
tocol description 203. The following discussion will first disclose the protocol description language, then pro- 
tocol interpreter 209, bootstrap 305, and error component 307, and finally protocol description 203 for the al- 

40 ternating bit protocol. 

The Protocol Description Language: FIG. 4 

FIG. 4 shows the instructions in a preferred embodiment of protocol description language 401 . The instruc- 
45 tions fall into two classes: those which perform general stack management and expression evaluation, shown 
in table 403, and those which perform operations which are particularly related to the execution of protocols, 
shown in table 405. 

As is apparent from table 403, protocol instruction interpreter 209 is a stack machine. The stack, maintained 
in protocol instruction interpretation data 311, is a standard integer size push-down stack. The PUSHJiYTE 

so and PUSHJ/VORD instructions permit data to be pushed onto the push-down stack. The other instructions 
take their operands and parameters from the top of the stack and push their results back onto the top of the 
stack. When a stack overflow or underflow occurs, interpreter 209 ceases executing the protocol, error com- 
ponent 307 sends an error message to the other protocol apparatus 107, and error component 307 then waits 
for an error handling message from the other protocol apparatus 107. Of course, how the other protocol ap- 

55 paratus 107 responds to the error message is part of the protocol described in protocol description 203. The 
same thing happens if an arithmetic error such as a zero divide or an integer overflow occurs. 

The functions of the instructions in table 405 are generally clear from the table; however, certain instruc- 
tions require a more detailed explanation. Beginning with the instructions in finite state machine control 407, 

7 



BNSOOCIO:<£P 0565997A2> 



# 



EP 0 555 997 A2 

contains the current byte position in the state being executed. At 1006, prot is set to the value of cur_state, 
so that execution starts at the first byte of the state. The while loop indicated at 1007 continues to execute as 
long as prot has a non-0 value, i.e., essentially until a return statement transfers control out of transition. 
The body of the while loop is a switch statement which contains a case for each of the instructions in pro- 

5 tocol description language 401. On each iteration of the loop, the variable prot is incremented by 1, so that it 
points to the next byte in the state. The value of that byte determines which case is executed. If there is no 
case corresponding to that value, default case 101 5 is executed, which puts interpreter 209 into the error state 
and thereby transfers control to error 307. Where required, a case further contains debugging code and as- 
sertions to check whether requirements for the execution of the instruction are fulfilled. If interpreter 209 is 

w only used with fully tested and verified protocol descriptions 203, the assertions and debugging code may be 
disabled. 

Fragment 1001 shows two cases in addition to default case 1015: those for NXT and l_NXT With NXT 
1011, the case simply pops the value at the top of the stack (i.e., the next state), checks whether the value 
is in the range of values for states, and returns the value. With l_NXT, the value of the next state is in the 
15 code, and not on the stack, so the case increments prot by one, checks whether the value at that point in the 
code is within the range, and returns the value. 

Implementation of Bootstrap 305:FlG.5 

20 In a preferred embodiment, Bootstrap 305 is implemented as a state of interpreter 209. Unlike the other states, 
which are defined by the protocol description loaded in by bootstrap 305, bootstrap 305 and error 307 are re- 
quired for the execution of the general protocol and therefore must be built into a protocol apparatus 301 before 
a protocol description 203 can be loaded. 

Since these two states are required for the general protocol, they are the only ones that enforce a prede- 

25 fined format on incoming messages, and that must require, the presence of certain kinds of data to permit 
checking of the general protocol message. As soon as these two states have successfully received a general 
protocol message with protocol description 203, they hand off control of the general protocol apparatus to the 
protocol description 203. 

In a preferred embodiment, bootstrap 305 is implemented with a single call run (BOOTSTRAP). Procedure 
30 run () is the implementation of interpreter 209 in a preferred embodiment. The procedure is reproduced com- 
pletely below. 
run(S) 

{ int n = s; 

while (n >= 0 && n <= SMAX && State[n].cont) 
35 n = transition(n); 

return n; 

} 

run is a loop which invokes the procedure transition with a state number, transition then puts interpreter 209 
into the proper state of protocol description 203 or the states which implement bootstrap 305 or error 307. The 
40 loop ceases execution when a value which is out of range of the legal state numbers is received. Thus, when 
invoked with BOOTSTRAP, a constant indicating the bootstrap state, the run simply puts interpreter 209 into 
the bootstrap state. 

Most of the concepts involved in implementing an embodiment of protocol apparatus 301 can be illustrated 
using an implementation of bootstrap 305. In a protocol apparatus 301 employing such an implementation, the 

45 code for bootstrap 305 would always be present in protocol instruction interpreter memory 309. 

For a general understanding of bootstrap 305, the flow chart of FIG.5 suffices. As shown in oval 503, boot- 
strap implementation 501 waits for the general protocol message from the remote protocol apparatus 107. 
When the message comes, it is loaded into a buffer in protocol instruction interpreter data 311. Next, the mes- 
sage is checked. First, a checksum is performed, to make sure the message is uncorrupted. If the checksum 

50 is non-zero, a transmission error has occurred, and the machine returns to the start of the bootstrap state (di- 
amond 505, 507). If the checksum is zero, a check is made if the message has the correct type (diamond 509). 
In a preferred embodiment, the first instruction is required to be the definition of the BYTEORDER for the lower 
interface. This byte-order definition specifies the order in which the bytes in a word sent according to the pro- 
tocol are transmitted across the lower level interface: most or least significant byte first It need not match the 

55 byte-order used in either the receiving or the sending entity. If the message is not a valid protocol description 
203, interpreter 209 enters error 307 (511). 

If the message is a valid protocol description 203, the contents of receive buffer is assigned to the initial 
state of the newly loaded protocol, and control is transferred to that state (box 515). A full implementation 1101 
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at byte 18 is reserved for the checksum which bootstrap 305 uses to check for correctness of transmission. 

Portion 807 is state 1 of the portion of the finite state machine which receives messages. In this state, 
the finite state machine waits for a message (byte 0). When the message arrives, it is placed in RBUF. At bytes 
2 through 12, the finite state machine writes a value indicating an acknowledgment (in this case, the charac- 
ter 'A') into the transmittal buffer, obtains the sequence number in the last byte of RBUF, copies the sequence 
number into TBUF following the 'A', and sends the acknowledgment. At bytes 14 through 20. the finite state 
machine compares the value of the sequence number retained in VAR_E with the sequence number in the 
last byte of RBUF. If they are the same, indicating that the received message had the right sequence number, 
bytes 23 through 33 are executed; otherwise, state 1 is again executed from the beginning, as shown at byte 
34. In bytes 23 through 31, the sequence number saved in VAR_E is subtracted from 1 and the result saved 
in VAR_E again. Then, the message is sent to its destination and state 1 is again executed from the beginning. 

FIG. 9 shows how the portion of the alternating bit protocol which sends messages is implemented in a 
preferred embodiment. In the preferred embodiment, protocol apparatus 107 in which send portion 901 is im- 
plemented is a protocol apparatus 201 or 301 which is sending to a protocol apparatus 301. Consequently, the 
send portion is implemented in protocol description language 401 and includes instructions which download 
receive portion 801 to the receiving protocol apparatus 301. 

The buffers and variables used in portion 901 are defined in part 803 of FIG. 8. In the prototype, buffers 
0 and 1 are preset to each contain a message; as may be seen from part 809 of FIG. 8, buffer 0 (named M0) 
is set to the ASCII character 'M' with the sequence number *0" appended to it, while buffer 1 is set to the ASCII 
character 'M* with the sequence number "1 " appended to it. The buffer R_run contains the code of portion 807, 
while the buffer Rjni contains the code of portion 805. The buffer R_ack, finally, is used for the acknowledge- 
ment received from receiver 801. There are two variables; VAR_S, which holds the sequence number which 
is to be attached to the message, and VAR_CNT, which is a count of the number of bytes sent by the sender. 

Returning to FIG. 9, the allocation and initialization of the sender buffers and variables defined in 803 takes 
place in section 903, which is state 0. In bytes 0-13, VAR_S and VAR_CNT are both allocated and set to 0; in 
bytes 14 and 15, receiver initialization code 805. contained in the buffer R_ini, is sent to the receiver; in bytes 
16 and 1 7, the code 807 for state 1 of the receiver, contained in the buffer R_run, is sent to the receiver. These 
lines 905 thus perform the downloading of protocol description 203 to the receiving protocol apparatus 301. 
At byte 18, finally, the l_NXT instruction starts execution of state 1 907. 

At bytes 0-2 of state 1 907, the current value of VAR_S is pushed onto the stack. At byte 3, SEND takes 
its parameter from the top of the stack; thus, if VAR_S has the value 0, the message in buffer M0 is sent; if it 
has the value 1, the message in buffer M1 is sent. In an embodiment for use in an actual communications sys- 
tem, there would be code preceding the SEND instruction which employed the OBTAIN instruction to obtain 
a byte of data to be sent and place the data in buffer M0 or M1 . depending on the value of VAR_S, and then 
employed CPY_BYTE to append M 0" or "1" to the data, again depending on the value of VAR_S. 

The code in bytes 4-8 receives the acknowledgment from the receiver and pushes it onto the stack. As 
pointed out in the discussion of the receiver, the acknowledgment has the form 'A<sequence_number>. The 
top byte of the stack consequently should contain *A and the next byte should contain the sequence number. 
In bytes 9-11. the top byte is checked to see whether it contains 'A. If it does, bytes 14-31 are executed; other- 
wise, execution continues at byte 32. Bytes 14-31 check whet her the acknowledgement has the right sequence 
number; if it does, they set VAR_S to the next sequence number. More specifically, bytes 14-20 check whether 
the sequence number in the acknowledgment is the same as the value of VAR_S. If it is not, execution con- 
tinues at byte 32; if it is. VAR_S is set to its new value by subtracting its current value from 1 (bytes 23-31). 

The code in bytes 32-54 updates VAR.CNT and terminates state 1 if the number of messages is greater 
than the constant NR_MSGS, defined in 803 to be 32765. In bytes 32-40. 1 is added to the current value of 
VAR_CNT. In bytes 41-47, VAR_CNT is pushed onto the stack, the most and least significant bytes of NR_MSGS 
is pushed onto the stack, and the two values are compared. If VAR_CNT>=NR__MSGS, bytes 50-52 put the 
value -1 on the stack. NXT returns that value to run, which thereupon terminates, as previously explained. 
Otherwise, byte 54 is executed, which causes state 1 907 to again begin execution. 

Performance of Protocol Apparatus 201 or 301 

The performance of the implementation of the alternating-bit protocol just described was compared with 
the performance of an implementation in which the sender and receiver were simply coded in the "C" program- 
ming language. The extra overhead caused by the use of protocol description 203 and interpreter 209 instead 
of a "C" program ranged from 10-30%, depending on the length of the message being transmitted (longer mes- 
sages have the lower overhead). In many applications, the extra overhead will be offset by the fact that the 
protocol apparatus of the invention can interpret any protocol for which there is a protocol description 203. Fur- 
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apparatus; and 

employing the specific protocol to communicate with the first protocol apparatus. 

7. The method set forth in claim 6 further characterized by: 

in the first entity, 

receiving a second general protocol message which includes a protocol specifier specifying the 
protocol description; 

responding to the second general protocol message by determining whether the specified protocol 
description is accessible to the first entity; 

if the specified protocol description is accessible, employing the first protocol description interpre- 
tation means to interpret the specified protocol description; but 

if the specified protocol description is not accessible, sending a first error message and thereupon 
performing the step of receiving the first general protocol message. 

8. Protocol apparatus (301) for communicating in a distributed system, the apparatus being characterized 
by: 

means (305) for receiving a first general protocol message, the first general protocol message in- 
cluding a protocol description (203) which describes a specific protocol and which employs a protocol de- 
scription language which is independent of any particular implementation of the protocol apparatus; and 

means (209) for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as required to communicate 
using the specific protocol. 

9. The protocol apparatus set forth in claim 8 further characterized in that: 

the means for receiving further checks the first general protocol message. 

10. The protocol apparatus set forth in claim 8 further characterized in that: 

the first general protocol message includes a parameter (415) for interpreting protocol data trans- 
ferred according to the specific protocol; and 

the means for responding to the first general protocol message interprets the protocol data accord- 
ing to the parameter. 

11. The protocol apparatus set forth in claim 8 further characterized in that: 

the protocol apparatus further includes error handling means (307); 

the means for receiving the first general protocol message further receives a second general pro- 
tocol message including a protocol specifier (1307) specifying the protocol description; and 

the means for responding to the first general protocol message further responds to the second 
general protocol message by determining whether the specified protocol description is accessible and if 
the specified protocol description is accessible, interpreting the specified protocol description, but if the 
specified protocol description is not accessible, sending a first error message. 

12. Apparatus for communicating in a distributed system, the apparatus being characterized by: 

first protocol apparatus (301) for communicating using a general protocol and 
second protocol apparatus (301) for communicating using the general protocol, 
the first protocol apparatus including 

means (209,903) for providing a first general protocol message which includes a protocol descrip- 
tion (203) which describes a specific protocol and which employs a protocol description language which 
is independent of any particular implementation of the second protocol apparatus; and 

means (209,907) for employing the specific protocol to communicate with the second protocol ap- 
paratus after providing the first general protocol message; and 

the second protocol apparatus including 

means (301) for receiving the first general protocol message from the first protocol apparatus; and 
means (209) for responding to the first general protocol message which are capable of interpreting 

the protocol description language and which interpret the protocol description as required to communicate 

using the specific protocol. 

13. Peripheral apparatus for communicating information using a protocol, the apparatus being characterized 
by: 

means (111) for transferring the information according to the protocol; 
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/* variable 
/• variable 



i' - 

cnt' 



sender side 
- sender side 



/* byteorder */ 

/• number of test messages sent •/ 



/* 

B_0, 

TBUF, 2, 
TBUF, 2, 
VAR_E, 1, 
RBUF, 

1, RBUF,/* 
1, /• 
0, /• 



initialization Buf(R_lniJ; recvd In StatefO] 



input becomes Stated] 
execute it */ 

room for the checksum, 



required on 1st msg */ 
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/•OV 


I_RBCV, RBUF, 






/•2V 


I_CPY_8TTE, TBUF, 


o. 


'A', 


/*6V 


I_PUSH_BYTE_VAR, 


RBUF, 


1. 


/*9V 


H_CPY_BYTB,~ TBUF, 


1. 




/*12V 


I_SEND, TBUF, 






/•14V 


I_PUSH_BYTE VAR, 


RBUF, 




/♦17V 


i push" Bm'vxR, 


VAR_E, 


o. 


/•20V 


EO, 






/•21V 


IF, 34, 


/• e « 


rbuf [1] 


/•23V 


I PUSH BYTE, 


1, 


/•25V 


I PUSH BYTE VAR, VAR E, 


0, 


/•28V 


MINUS, 






/•29V 


H_CPY_BYTE, 


VAR_E, 


0, 


/•32V 


XJhCCE?T, 


RBUF, 




/•laV/ 


I_NXT, 1 


/* stay 


in same 



); 



state •/ 



BITE MsgOU - ( /* message Buf[M0J, received in Buf [RBUF] */ 
' M* , 0 

809 ,; 

BYTE Magin - { /• message Buf [Ml), received in Buf [RBUF] */ 



' M* , 1 
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FIG, 10 



1003 

transition (n) 

{ BYTE bl, *cur_state - Statefn] .cont; 

static int Stack (SMAX+1]; 

register BYTE *prot; 1005 

register int wO, wl, w2 # i; 

register int *sp - fcStack [SMAXJ ; 

" y 1009 



1007- 



prot - cur_state; 
while (prot) { 

switch ( w prot++) { 



/•*»** FSM CONTROL *»***/ 



10 



10 



" case NXT: 

assert (sp < tStack [SMAX] ) ; 
wO « POP; 

1 debug(*next %d0, wO, 0, 0, 0); 

if (wO < 0 I | wO > SMAX || !State(wO] .cone) 

return ERRORST ATE ; 
return wO; 
case I_NXT: 

wO • *prot++; 
3 debug {"next IdO, wO, 0, 0, 0); 

if (wO < 0 I I wO > SMAX II !State(wO] .cor.o 

return ERRORST ATE ; 
return wO; 



f default: 

•015 debugCError <%d>0, •prot, 0, 0, 0) ; 

^ return ERRORSTATE; 

> > 
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(S) Apparatus and methods for implementing protocols. 

(57) Apparatus and methods for communicating 
using protocols. The apparatus and methods 
employ protocol descriptions written in a de- 
vice-independent protocol description lan- 
guage. A protocol is executed by employing a 
protocol description language interpreter to in- 
terpret the protocol description. Communi- 
cation using any protocol for which there is a 
protocol description may be done by means of a 
general protocol. The general protocol includes 
a first general protocol message which includes 
a protocol description for a specific protocol. 
The protocol apparatus which receives the first 
protocol message employs a protocol descrip- 
tion language interpreter to interpret the in- 
cluded protocol description and thereby to 
execute the specific protocol. The protocol ap- 
paratus may also be made to adapt to its envi- 
ronment by encaching protocol descriptions 
which were received in an earlier first general 
protocol message and interpreting an encached 
protocol description in response to a second 
general protocol message which includes a 
protocol identifier specifying the encached pro- 
tocol description. 
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